... instead of using unnamed tuples and long parameter lists.

This will allow us to output warnings if the (non-blocking) delivery
gets too far behind, because we can tell how long it took between
enqueuing the event and actually sending it.

This commit adds another migration to said database, so I slightly
refactored the migration code.

This fixes [this integration test failure](https://github.com/stacks-network/stacks-core/actions/runs/20749024845/job/59577684952?pr=6762),
caused by the fact that event delivery wasn't complete by the time the
assertions were made.

Doing this work in the RunLoop implementations' startup code is *almost*
the same thing, but not quite, since the nakamoto run loop might be
started later (after an epoch 3 transition), at which point the event DB
may already have new items from the current run of the application,
which should *not* be touched by `process_pending_payloads`.

This used to not be a problem, but now that that DB is used for the
actual queue of the (concurrently running) EventDispatcherWorker, it has
become one.

This is like 72437b2, but it works for
all the tests instead of only the one.

While only that one test very obviously failed, the issue exists for
pretty much all of the integration tests, because they rely on the
test_observer to capture all relevant data.

Things are fast enough, and therefore we've only seen one blatant
failure, but

1) it's going to be flaky (I can create a whole lot of test failures
   by adding a small artificial delay to event delivery), and
2) it might actually be *hiding* test failures (in some cases, like e.g.
   neon_integrations::deep_contract, we're asserting that certain things
   are *not* in the data, and if the data is incomplete to begin with,
   those assertions are moot).

…g-event-delivery

As per this thread: stacks-network#6795 (review)

I used the same table/column name and semantics that we use elsewhere
for the same purposes.

Also fixed a comment typo.

…event-dispatcher-tweaks

…g-event-delivery

Thanks Hank for the tip!

Not sure why this wasn't caught in the pre-commit hook, I'd have assumed
the checks are the same.

stacks-network#6795 (comment)

…g-event-delivery

The logic is slightly tricky here, because the size of the queue (the
max number of in-flight requests before we start blocking the thread) is
implemented through the `bound` parameter of the `sync_channel`, but
those two values aren't actually the same.

See the comment at the top of `EventDispatcherWorker::new()` for
details.

See the discussion in stacks-network#6543
for some background.